CI: Updating release "nightly" breaks pipeline #100

New issue

2021-07-03T13:44:40Z

jfowl commented

2021-07-03 13:44:40 +00:00

(Migrated from gitlab.com)

GitLab's CI release integration assumes that you are always creating a new release and never overwrite an old one.

So the pipeline will probably fail the second time it successfully runs on the master branch.

Working on real fix, workarounds inthe meantim

Remove the release-job from ci
or: Delete the "Nightly" release everytime a new commits lands on master

[GitLab's CI release integration](https://docs.gitlab.com/ee/ci/yaml/index.html#release) assumes that you are always creating a new release and never overwrite an old one. So the pipeline will probably fail the second time it successfully runs on the master branch. Working on real fix, workarounds inthe meantim - Remove the release-job from ci - or: Delete the "Nightly" release everytime a new commits lands on master

jfowl commented

2021-07-03 13:44:40 +00:00

(Migrated from gitlab.com)

assigned to @jfowl

jfowl commented

2021-07-03 14:55:30 +00:00

(Migrated from gitlab.com)

So apparently a CI job can only create, not delete or update releases:

$ curl --request DELETE --header "JOB-TOKEN: ${CI_JOB_TOKEN}" "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/releases/${RELEASE_TAG}"
{"message":"403 Forbidden"}

This means: Only release a release once. So what to do now?

Real "nightly" releases could be a thing: Have a pipeline run every 24 hours and create a "nightly-YYYY-MM-DD" tag for the last commit on master. That would mean many releases though...
Create a dedicated project token and store that in a secret env in the project settings.

Anyways, the issue needs to be addressed. I suggest deleting the last (publish:nightly) job from the CI for now.

So apparently a [CI job can only create, not delete or update releases](https://docs.gitlab.com/ee/api/index.html#gitlab-cicd-job-token): ```bash $ curl --request DELETE --header "JOB-TOKEN: ${CI_JOB_TOKEN}" "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/releases/${RELEASE_TAG}" {"message":"403 Forbidden"} ``` This means: Only release a release once. So what to do now? - Real "nightly" releases could be a thing: Have a pipeline run every 24 hours and create a "nightly-YYYY-MM-DD" tag for the last commit on master. That would mean many releases though... - Create a dedicated [project token](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) and store that in a secret env in the project settings. Anyways, the issue needs to be addressed. I suggest deleting the last (publish:nightly) job from the CI for now.

jfowl commented

2021-07-03 16:19:40 +00:00

(Migrated from gitlab.com)

mentioned in merge request !113

phesch commented

2021-07-03 16:38:21 +00:00

(Migrated from gitlab.com)

Maybe an option would be to save the build as an artifact instead. According to the Gitlab documentation,
it's possible to create a static link that will point to the latest version of an artifact (in this case, our build).
Using artifacts would mean that Gitlab takes care of deleting the old builds automatically (it preserves non-latest artifacts for some amount of time, I'm not sure how long exactly).

Of course, that would mean that the link to the nightly build might look a little weird.

Maybe an option would be to save the build as an artifact instead. According to [the Gitlab documentation](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#access-the-latest-job-artifacts-by-url), it's possible to create a static link that will point to the latest version of an artifact (in this case, our build). Using artifacts would mean that Gitlab takes care of deleting the old builds automatically (it preserves non-latest artifacts for some amount of time, I'm not sure how long exactly). Of course, that would mean that the link to the nightly build might look a little weird.

jfowl commented

2021-07-03 16:44:43 +00:00

(Migrated from gitlab.com)

That would probably not bother me.
Let me test your idea...

That would probably not bother me. Let me test your idea...

jfowl commented

2021-07-03 16:56:20 +00:00

(Migrated from gitlab.com)

Afaik the release would still point to the same tag it was originally created with.
So maybe the linked binaries could be updated by being links to latest artifacts.

But the release would still point to an old tag, have old source tar balls and an old date.

Afaik the release would still point to the same tag it was originally created with. So maybe the linked binaries could be updated by being links to latest artifacts. But the release would still point to an old tag, have old source tar balls and an old date.

phesch commented

2021-07-03 17:22:47 +00:00

(Migrated from gitlab.com)

Yeah, this idea doesn't integrate super well with Gitlab releases. It would probably work best if the nightly build was just linked in the README instead of being a release. I think you could probably also generate source tarballs as artifacts as part of the pipeline if you wanted those as well.

jfowl commented

2021-07-03 19:20:27 +00:00

(Migrated from gitlab.com)

Yep. So let's just link to the latest artifacts in the README.

jfowl commented

2021-07-03 19:42:39 +00:00

(Migrated from gitlab.com)

I'm working on changing the URLs in DEPLOY.md.

What is just "arm"?

![image](/uploads/2694bee1d3a1725129b0f31ca8856d54/image.png) I'm working on changing the URLs in [DEPLOY.md](./DEPLOY.md). What is just "arm"?

phesch commented

2021-07-03 19:58:58 +00:00

(Migrated from gitlab.com)

It's probably the arm-unknown-linux-musleabihf version from cross. As to which ARM version that corresponds to exactly, no idea.

It's probably the arm-unknown-linux-musleabihf version from [cross](https://github.com/rust-embedded/cross). As to which ARM version that corresponds to exactly, no idea.

jfowl commented

2021-07-03 20:41:05 +00:00

(Migrated from gitlab.com)

okay, I'll just leave it there for now.

timokoesters commented

2021-07-11 11:43:49 +00:00

(Migrated from gitlab.com)

mentioned in commit fcfb9b51de

mentioned in commit fcfb9b51de2c0a06d4c193be0416e7b1da4f7823

Sign in to join this conversation.