Add create deb packet in workflow

[khromenokroman]

@olofhagsand I suggest that packages be assembled to simplify the installation process, there are many problems here, for example, the history of dependency changes in the package, the platform for which the package is being assembled, but you can start with this

[khromenokroman]

@olofhagsand Added a more flexible system for getting the project version through an environment variable and a launch counter

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 53.47%. Comparing base (f5a60ce) to head (a3f0062). Report is 4 commits behind head on master.

Additional details and impacted files

[](https://app.codecov.io/gh/clicon/cligen/pull/115?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=clicon) ```diff @@ Coverage Diff @@ ## master #115 +/- ## ======================================= Coverage 53.47% 53.47% ======================================= Files 23 23 Lines 7691 7691 Branches 1784 1784 ======================================= Hits 4113 4113 Misses 2551 2551 Partials 1027 1027 ``` ------ [Continue to review full report in Codecov by Sentry](https://app.codecov.io/gh/clicon/cligen/pull/115?dropdown=coverage&src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=clicon). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=clicon) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://app.codecov.io/gh/clicon/cligen/pull/115?dropdown=coverage&src=pr&el=footer&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=clicon). Last update [f5a60ce...a3f0062](https://app.codecov.io/gh/clicon/cligen/pull/115?dropdown=coverage&src=pr&el=lastupdated&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=clicon). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=clicon).

[olofhagsand]

Got this error in github actions

Run actions/create-release@v1 
Error: Resource not accessible by integration

[khromenokroman]

@olofhagsand Let's try it like this. I understand that the problem is that there is no key when the pull request is made, I did the execution only in the master branch.

[YotaYota]

Not sure this solves the problem with the error in the build step. But I made an earlier attempt at debian packet with gbp. In this case I had a debian/rules which looked like:

!/usr/bin/make -f

%:
    dh $@

override_dh_auto_configure:
    ./configure --prefix=/usr

override_dh_auto_test:

a single debian/control file with 2 packages inside: libcligen-dev and libcligen7. Corresponding install files looked like:

$ cat libcligen7.install 
usr/lib/

$ cat libcligen-dev.install 
usr/include/cligen

this was since debian does not allow installs in include dir. I also had to add a DEBIAN/triggers:

activate-noawait ldconfig

and a postinst:

#!/bin/sh 
# runs ldconfig 
set -e 

case "$1" in 
   configure) 
     ldconfig 
     ;; 
   abort-upgrade|abort-remove|abort-deconfigure) 
     ;; 
esac 

This solved the issue of avoiding the include dir, but I had to skip the tests.

[khromenokroman]

There is currently an error in "Create deb packet" step:

Run actions/create-release@v1
Error: Resource not accessible by integration

Do you know why it errors out?

@YotaYota I think that's the problem, when performing GitHub Actions in the context of a pull request from a fork, secrets such as your GITHUB_TOKEN are not shared for security purposes. this means that any actions that require these secrets (for example, actions/create-release@v1) will not be able to get them and therefore will not be able to be executed. But I'm not sure exactly, maybe I'm wrong :)

[khromenokroman]

@YotaYota if there is a trigger activate-nowait ldconfig, then there is no point in the postinst script that does ldconfig

[khromenokroman]

@YotaYota a single debian/control file with 2 packages inside: libcligen-dev and libcligen7. Corresponding install files looked like: this is a good suggestion, we need to think about how to do it, thank you

[khromenokroman]

@YotaYota Not sure this solves the problem with the error in the build step. But I made an earlier attempt at debian packet with gbp. In this case I had a debian/rules which looked like: I don't have an error at the build stage.

[YotaYota]

There is currently an error in "Create deb packet" step:

Run actions/create-release@v1
Error: Resource not accessible by integration

Do you know why it errors out?

@YotaYota I think that's the problem, when performing GitHub Actions in the context of a pull request from a fork, secrets such as your GITHUB_TOKEN are not shared for security purposes. this means that any actions that require these secrets (for example, actions/create-release@v1) will not be able to get them and therefore will not be able to be executed. But I'm not sure exactly, maybe I'm wrong :)

Aha, so you think this will work in the main branch then? Maybe you've seen this build step pass on your account?

[YotaYota]

@YotaYota if there is a trigger activate-nowait ldconfig, then there is no point in the postinst script that does ldconfig

Ah, thank you! I learned something new :) Then that could be simplified

[khromenokroman]

There is currently an error in "Create deb packet" step:

Run actions/create-release@v1
Error: Resource not accessible by integration

Do you know why it errors out?

@YotaYota I think that's the problem, when performing GitHub Actions in the context of a pull request from a fork, secrets such as your GITHUB_TOKEN are not shared for security purposes. this means that any actions that require these secrets (for example, actions/create-release@v1) will not be able to get them and therefore will not be able to be executed. But I'm not sure exactly, maybe I'm wrong :)

Aha, so you think this will work in the main branch then? Maybe you've seen this build step pass on your account?

@YotaYota yes, everything works out correctly under my account

[khromenokroman]

There is currently an error in "Create deb packet" step:

Run actions/create-release@v1
Error: Resource not accessible by integration

Do you know why it errors out?

@YotaYota I think that's the problem, when performing GitHub Actions in the context of a pull request from a fork, secrets such as your GITHUB_TOKEN are not shared for security purposes. this means that any actions that require these secrets (for example, actions/create-release@v1) will not be able to get them and therefore will not be able to be executed. But I'm not sure exactly, maybe I'm wrong :)

Aha, so you think this will work in the main branch then? Maybe you've seen this build step pass on your account?

@YotaYota I was recently asked to make a small program I was doing, and it worked there https://github.com/khromenokroman/play_radio/blob/main/.github/workflows/main.yml

[YotaYota]

A suggestion for the control file could be:

Source: cligen
Section: devel
Priority: optional
Maintainer: roma55592@yandex.ru
Build-Depends:
 debhelper-compat (= 13),
 flex,
 bison,
 libnghttp2-dev,
 libssl-dev
Standards-Version: 4.5.0

Package: libcligen-dev
Architecture: any
Multi-Arch: foreign
Depends: ${misc:Depends},
         ${shlibs:Depends},
         libcligen7
Description: Cligen development package

Package: libcligen7
Architecture: any
Multi-Arch: foreign
Depends: ${misc:Depends},
         ${shlibs:Depends}
Description: Cligen library package

[YotaYota]

Allright, what should be added at the main repo to make the build go through? I assume it's a GitHub secret :thinking: ? Maybe you could provide a mini-guide on what should be added and what value? :) :pray:

[olofhagsand]

Where will the packages appear? Will there be a push of a package to https://github.com/orgs/clicon/packages?repo_name=cligen on every commit/push of master? I would like the package process triggered as an action on each commit, but I am not sure there should be an update of the release package on every commit. Maybe I misunderstand.

[khromenokroman]

Where will the packages appear? Will there be a push of a package to https://github.com/orgs/clicon/packages?repo_name=cligen on every commit/push of master? I would like the package process triggered as an action on each commit, but I am not sure there should be an update of the release package on every commit. Maybe I misunderstand.

@olofhagsand They will appear here

according to debian versioning, the package will have a version such as 7.1.0 minor major and fix and then there will be an update every commit and that will turn out to be 7.1.0-1 then 7.1.0-2 and so on and when the time comes to change it will turn out to be 7.2.0-1, 7.2.0-2

[khromenokroman]

A suggestion for the control file could be:

Source: cligen
Section: devel
Priority: optional
Maintainer: roma55592@yandex.ru
Build-Depends:
 debhelper-compat (= 13),
 flex,
 bison,
 libnghttp2-dev,
 libssl-dev
Standards-Version: 4.5.0

Package: libcligen-dev
Architecture: any
Multi-Arch: foreign
Depends: ${misc:Depends},
         ${shlibs:Depends},
         libcligen7
Description: Cligen development package

Package: libcligen7
Architecture: any
Multi-Arch: foreign
Depends: ${misc:Depends},
         ${shlibs:Depends}
Description: Cligen library package

@YotaYota I completely agree, it's a very correct proposal, I wanted to do it later, I didn't know if the assembly was needed at all, once we started, I agree with the proposal let's do it

[khromenokroman]

@olofhagsand @YotaYota comments have been corrected

[khromenokroman]

Allright, what should be added at the main repo to make the build go through? I assume it's a GitHub secret 🤔 ? Maybe you could provide a mini-guide on what should be added and what value? :) 🙏

@YotaYota in theory, nothing needs to be added, everything should already be by default if no one has changed anything https://www.youtube.com/watch?v=jEK07KPEjnY

[khromenokroman]

@olofhagsand @YotaYota i add to ci field, you can try to pass ci or not

permissions:
  contents: write
  pull-requests: write

[khromenokroman]

@olofhagsand I did getting the version through an environment variable, it seems to me that this is not a very good story, the next step I think will be to get the version when building the project and then take it to ci. for example, what to do, but this is the second step it seems to me

all: cligen $(APPS)
    echo "$(CLIGEN_VERSION)"."$(CLIGEN_MAJOR)"."$(CLIGEN_MINOR)" > version.txt

[khromenokroman]

@olofhagsand @YotaYota I also added task launch dependencies

[YotaYota]

@khromenokroman Great effort, thank you very much! :bow:

@olofhagsand : Another idea is that the GitHub Action trigger could be changed to "workflow dispatch" to instead have a manual click to build :thinking:

[khromenokroman]

@olofhagsand @YotaYota Another idea is that the GitHub Action trigger could be changed to "workflow dispatch" to instead have a manual click to build 🤔 I also think this is a good idea, but usually I want the package to be the freshest, and therefore it is necessary that the package be created when the commit is made, but you can make the build run on click, I really did not try to have it all in one task, perhaps it will need to be divided into 2 steps

[khromenokroman]

@olofhagsand @YotaYota I think the next step will be to make packages for different versions 22.04 20.04 ...

[khromenokroman]

@olofhagsand @YotaYota are we going to make a pull request?

[olofhagsand]

Can you please squash it and I will merge

[khromenokroman]

Can you please squash it and I will merge

@olofhagsand fixed

[olofhagsand]

You need to edit the commit message. The squash just appends all individual commits into one huge commit message. Please summarize it.

[olofhagsand]

Also I notice the base is ubuntu-20.04. Why not ubuntu-latest as in the other rules, or at least ubuntu-22.04?

[khromenokroman]

Also I notice the base is ubuntu-20.04. Why not ubuntu-latest as in the other rules, or at least ubuntu-22.04?

@olofhagsand if I install 22.04, I will not be able to run on debian 11, I assumed that most of them use debian 11, few people still use debian 12, but if necessary, I can install 22.04 or lates, put it?

[khromenokroman]

You need to edit the commit message. The squash just appends all individual commits into one huge commit message. Please summarize it.

@olofhagsand I don't really understand git :) Did I do the right thing now?

[olofhagsand]

if I install 22.04, I will not be able to run on debian 11, OK

[olofhagsand]

No the commit message was not edited (can do with git rebase -i HEAD~2) Edited the squash commit message and pushed it to master. Note that most recent commits after the squash are not included in this push, please check if they are necessary: bea6a4e203e37b02af2b76573aae8db0d56bd1a7 a3f00622b1b375cb0fc825a277c90af81f7eaa43 Also, there are eight warnings on the form:

reset-run-number
The following actions use a deprecated Node.js version and will be forced to run on node20: mlilback/build-number@v1. For more info: https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/

Finally, I was expecting the packages to appear under "Packages" not "Releases"?

[khromenokroman]

Finally, I was expecting the packages to appear under "Packages" not "Releases"?

@olofhagsand as far as I know, this section is intended for another No the commit message was not edited (can do with git rebase -i HEAD~2) I did so, apparently I made a mistake somewhere, thank you

reset-run-number
The following actions use a deprecated Node.js version and will be forced to run on node20: mlilback/build-number@v1. For more info: https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/

as far as I know, this is due to the fact that node js has been updated, but this should not affect the work, I will see what can be done