build(deps): bump actions/deploy-pages from 1 to 2 #701
Conversation
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
dependabot
bot
added
the
dependencies
|
suppose we need remove gh_pages branch to enable deploy pages? |
@evelikov highlighted the following steps to fully enable gh pages. I believe that removal gh_pages is optional in this respect (i.e. it becomes an obsolete branch once action is fully enabled). Here is this write up: #659 (comment) |
|
The problem with current actions setup for GH pages is that it's not easily re-triggerable. For example, here is action run when 2.18.0 was published: https://github.com/intel/libva/actions/runs/4543957752. It failed most likely since we did not actually perform required libva git project settings adjustment to enable posting of pages from our action. But problem is that even if I will fix project settings right now I can't retrigger this workflow - it simply miss re-trigger button for some reason. And I don't want to actually create new release just to retrigger a workflow. Considering that current pages are outdated with 2.13 release, I suggest to step back and do the following:
After that we can stop and consider that to do next. In a sense we can actually do nothing and just provide pages for the latest state on master which will be a candidate for new release. Or we can return back to original plan, though we will step again into the same problem that it won't be verifiable. What makes the most sense to me is actually generate pages for few states of the uAPI: 1) for master, 2) for latest release, 3) maybe for few latest releases. I would also do that from the master branch only to allow fixes of the posted materials when needed. @XinfengZhang, @evelikov : please, let me know your thoughts. If you are ok with the plan I can start doing it. |
|
@dvrogozh do you need to retrigger it manually, or is that a nice-to-have kind of feature? If it is a case of "need" then surely one will be creating a proper new release/tag. Thus the fix will shared with the wider community, right? |
|
No, not right. As of now I need to change github project settings and I don't have any way to retrigger workflow. So, if I will change project settings now, we will need to wait I don't know how long till we will post a new release, And if something won't work, we will wait again. This does not make sense to me. If there is a workflow I want to have a reasonable way to run/rerun it. As of now I don't have it. If there is a bug in workflow - I would fix it and again want a way for it to work w/o any release posting if no change was done to the actual library. |
I think this is the biggest concern here. It's even more alarming, that it comes from one of the maintainers. |
|
ask a dumb question , how about a tag, not official release, if a new tag will trigger the flow? |
|
check previous failure looks it is because we are still deploy the doc from gh-pages, but in the github settings now ,could I use a latest tag(a prerelease tag) to test it? |
You don not actually listen to the issue I am trying to raise regarding current supposed setup for pages deployment. |
|
As the workflow rules at the top say - it triggers on published aka releases. Whereas for the "I want to re-trigger manually" - you cannot AFAICT. As with any feature, if you want to try/test the changes simply push to your And yes, it's perfectly fine to push a release to address problems with the website. Releases are cheap, plus people generally appreciate more frequent ones. @dvrogozh I am (repeatedly) highlighting the elephant in the room. The current libva maintainership is very very poor - the questions you've raised flagging a part of it. Sorry if that upsets anyone, it is just the unfortunate facts. |
thanks , will improve this part, the response TPT , and sorry for any inconvenience . |
|
@dvrogozh I will release 2.19.0 soon, lets check whether the github setting works. |
XinfengZhang
force-pushed
the
dependabot/github_actions/actions/deploy-pages-2
branch
from
f9ad877
to
f6a02b0
Compare
Bumps [actions/deploy-pages](https://github.com/actions/deploy-pages) from 1 to 2. - [Release notes](https://github.com/actions/deploy-pages/releases) - [Commits](actions/deploy-pages@v1...v2) --- updated-dependencies: - dependency-name: actions/deploy-pages dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
XinfengZhang
force-pushed
the
dependabot/github_actions/actions/deploy-pages-2
branch
from
f6a02b0
to
6d39215
Compare
|
anyway， I merge this one firstly, following steps could be discussed in a new issue |
dependabot
bot
deleted the
dependabot/github_actions/actions/deploy-pages-2
branch
Bumps actions/deploy-pages from 1 to 2.
Release notes
Sourced from actions/deploy-pages's releases.
... (truncated)
Commits
73e62e6Merge pull request #140 from actions/cut-v2b254707Update the deployment API endpoints used by the api-client moduleYou can trigger a rebase of this PR by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)