Refactor docker build/push workflow action

[amaltaro]

Fixes #11646

Status

ready

Description

I created a new repository and tested these changes to make sure that we can now build at least reqmgr2ms-unmerged package, which was failing for the last couple of tags.

Summary of changes is:

• removed dependency on docker/build-push-action@v1, instead, push the docker image in the same step as we build it.
• removed the Images step, instead simply added it to the same step building and publishing the image
• created a SERVICE_NAME job wide environment variable with the WMCore component to be built/published.
• created a CERN_REGISTRY step wide environment variable (all my attempts to set it job wide failed, either with only $, or with ${ or with ${{).

Is it backward compatible (if not, which system it affects?)

YES

Related PRs

Resolving unresolved issues from:
#11638
#11651

External dependencies / deployment changes

None

[vkuznet]

I need more info about provided logic, see inline.

[vkuznet]

Why do we need svn to checkout github repo? Why not to use git for that?

[amaltaro]

For this question, please refer to: #11639 for full context.

[vkuznet]

Alan, even though ticket lists that you swap curl with svn it does not provide a reason, and neither address why you use curl/svn to get git repo files, why not to use (tool designed for that) git? Please note that in all CMSKubernetes yaml file I always relies on git, e.g. RUN git checkout tags/$TAG -b build see https://github.com/dmwm/CMSKubernetes/blob/master/docker/dbs2go/Dockerfile#L33

[amaltaro]

@todor-ivanov has done the research on the svn util. My understanding is that with svn, we can fetch a sub-directory of the repository, while git does not provide this capability and we would have to clone the whole repository for each of the 11(?) services that we have setup in the actions workflow.

[vkuznet]

ok, thanks for providing the reason. Said that, this line is not doing what the comment is saying, i.e. it will fetch latest subdir and not a particular tag. I do not know svn enough to answer if it can fetch proper tag of sub-dir, but curl cat fetch tarball of particular tag, and git indeed will fetch entire repo for that tag. So, we should fix either svn or switch back to curl to fetch exact tag of the repo.

[amaltaro]

Valentin, the CMSKubernetes code that we check out isn't really tagged (we always fetch what is in HEAD).
The PYPI_TAG is indeed used, but then in the scope of WMCore (used for the tag in pypi and the docker build argument).

Having said that, I would say it works as expected and there is nothing to be changed here.

[todor-ivanov]

Hi @vkuznet @amaltaro

with svn, we can fetch a sub-directory of the repository, while git does not provide this capability and we would have to clone the whole repository for each of the 11(?) services that we have setup

Yes this is the exact reason.

So, we should fix either svn or switch back to curl to fetch exact tag of the repo

SVN is fully capable of fetching particular tag.

[vkuznet]

why do we need to sleep, what do you mean that PyPi packages are available? Once you download them they should be available and I don't see any needs for sleep. Why 300 and not any other number?

[amaltaro]

this we discussed when we were commissioning the build workflow. There is a delay between publishing a package to the PyPi repository and fetching it. This 5min is a fair enough commitment that we came up with in the past and which allows us to use the PyPi package when building the docker image.

[cmsdmwmbot]

Jenkins results:

• Python3 Unit tests: succeeded
  • 1 tests no longer failing
  • 1 changes in unstable tests
• Python3 Pylint check: succeeded
• Pylint py3k check: succeeded
• Pycodestyle check: succeeded

Details at https://cmssdt.cern.ch/dmwm-jenkins/view/All/job/DMWM-WMCore-PR-test/14317/artifact/artifacts/PullRequestReport.html

[amaltaro]

@vkuznet @todor-ivanov if there is no further comments and or concerns, I would like to get it merged because deployment is scheduled for tomorrow and we still need to have another testbed upgrade this afternoon.

[vkuznet]

@amaltaro , I provided my concerns, and it is up to you to disregard them or not. I am not fan of having sleep commands as they can lead to incorrect results, the publishing to pypi should be separated from build in my opinion. The svn usage is odd with github repos in my view too. I only provide my feedback on what I saw in PR, but it is up to you to decide if merge is sufficient or not.

[amaltaro]

@vkuznet Valentin, I will get it merged then, but I am happy to keep these discussions ongoing and in case we decide to change things, we can follow up with a new issue and/or PR as well.

However, let me add a few more content on your comments:

1. about the sleep: sadly, it was a commit made directly via GH Web UI, hence we do not have any background information with that. This ticket Add initial draft for building WMCore images via CI/CD #11339 has extra historical data as well, of when we were debating of a) creating the docker image from pip'; or b) creating it from parsing the requirements.txt file. In the end we agreed upon option a) and later we noticed that there is a delay to have the pypi package tag indexed and available for download, reason why we added that sleep (likely together via a Zoom call!!).
2. "having sleep commands as they can lead to incorrect results": I do not understand which results can be wrong with a sleep.. The reverse can happen though without a sleep, as explained above.
3. "the publishing to pypi should be separated from build in my opinion": this is already the case. Building and upload of Pypi packages are separated, as it is building of pypi and docker images.
4. for the svn: there was an alternative that I provided to separate the wmagent dockerfiles, such that we could remain relying on curl. Nonetheless, the workflow action already provides svn and it is not as heavy as cloning the whole repository. What is your specific concern here? Further details can be followed up in this ticket Substitute curl with svn in gitHUb actions #11639 and all its references as well (there was plenty of back and forth between @todor-ivanov and myself)

[amaltaro]

Just FYI, we have finally recovered from the failure mode between 2.2.2rc6 and 2.2.2rc11. Release 2.2.2rc12 was just built and all the docker images were successfully created and published. I am now going to deploy this release to testbed.

[todor-ivanov]

Sorry for the late review - it all looks good
Thanks @amaltaro